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BEST AVAILABLE COPY 

Description 

MULTIMEDIA DATA REPRODUCING APPARATUS, 

AUDIO DATA RECEIVING METHOD AND AUDIO 

DATA STRUCTURE THEREIN 
Technical Field 

[ 1 ] The present invention relates to audio data transmission, and more particularly , to a 

rrultimedia data reprodxing apparatus, a method of receiving audio data using a hyper 
text transport protocol (HTTP) and an audio data structure used for the apparatus and 
method. 

Background Art 

[2] FIG. 1 illustrates a process of requesting an audio file from a server and receiving 

the requested file by a terminal receiving data over the Internet. 
[3] Referring to FIG. 1, web browser software, such as Internet Explorer, is installed 

on a terminal 1 10 receiving data over the Internet. The terminal 1 10 can request web 

data stored on a server 120 to be transmitted using a predetermined protocol via the 

web browser software. 

[-4] When the Lerrriiriul 110 requests an CLxdicao n»e, which is a kind of" compressed 

audio file, the terminal 110 transmits a file request message 130 to the server 120. The 
server 120 transmits a response message 140 to the terminal 110 and then transmits 
audio data to the terminal 1 10. 

[5] Here, a generally used protocol is an HTTP protocol. The received audio data is 

temporarily stored in a buffer memory included in the terminal 110, decoded by a 
decoder reprodjeing data, and output as analog axlio. 

[6] In detail, markup resource data includes HTML files, image files, script files, audio 

files, and video files. The terminal 1 10, which receives the markup resource data, is 
connected to a web server, on which the markup resource data is stored, using the 
HTTP protocol. For example, if a user wants the terminal 1 10 to access a site 
wwwxompany.com and download an audio.ac3 file, the terminal 1 10. executes the 
browser and accesses the server 120 by typing in 'httpy/www.company.com' in URL 
(Uniform Resource Location) field. After accessing the server 120, the file request 
message 130 is transmitted to the server 120. The server 120 transmits the response 
message 140 to the terminal 1 10. 

[7] The server provides the stored markup resource data. Since the terminal 110 

requests the audio.ac3 file, the server 120 transmits the sudio.ac3 file to the terminal 
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110. The terminal 1 10 stores the received audio.ac3 file in the buffer memory. The 
decoder included in the terminal 110 decodes the audio.ac3 file stored in the buffer 
memory and outputs the decoded file as analog ajdio. 

[8] In a conventional method of transmitting markup resource data, the terminal 1 10 

requests a complete file and the server 120 transmits the complete file, or when a large 
file, such as audio data, is transmitted, the terminal 110 requests the file by defining in 
advance a range to be transmitted and the server 120 transmits a portion of the file cor- 
responding to the range. 

[9] However, when data is encoded temporally, and when data to be transmitted is 

defined according to a time at which it is to be transmitted, as in audio data, it is 
difficult to use the conventional method. For example, if various kinds of aidio files, 
such as MP3, MP2, and AC3, exist, when the same time information of the audio files 
is transmitted to the server 120, and when audio data corresponding to the time in- 
formation is requested, it is difficult to use the conventional method since locations of 
files corresponding to the time information are different for each kind of audio file. 
Disclosure of Invention 

Technical Solution 

[10] Tnc present invention provides a method of receiving aidio data using an HTTP 

protocol, not a complex aidioMdeo streaming protocol, a structure of received audio 

meta data, and a structure of axlio data. 
[11] The present invention also provides a multimedia data reproducing apparatus 

capable of reprodbcing aidio data in synchronization with audio data and video stored 

in a DVD. . 

Advantageous Effects 

[12] As described above, according to embodiments of the present invention, audio data 

is received using an HTTP protocol, not a complex audioMdeo streaming protocol, 
and output in synchronization with video data. 

[13] For example, a DVD includes movie contents and video in which a director 

explains procfacing procedures of the movie (directors cut). The explanation is mostly 
prodbced in one language. Accordingly, a film prodring company mist produce a 
special DVD to provide Korean content. Therefore, since only audio prodbced with 
various languages is downloaded over the Internet and output in synchronization with 
orignal DVD video, problems of producing a special DVD can be overcome. 

Description of Drawings 

[ 14] FIG. 1 illustrates a process of requesting an audio file from a server and receiving 



the requested file by a terminal receiving data over the Internet; 
[ 15] FIG. 2 is a block diagram of a terminal; 

[16] FIG. 3 is a block diagram of a server; 

[17] FIG. 4 illustrates a process by which a terminal receives audio data from a server 

using meta data; 

[18] FIG. 5 is a table showing request messages and response messages used to 

comrrunicate between a terminal and a server; 

[19] FIG. 6 illustrates the configuration of an audio.ac3 file; 

[20] FIG. 7 is a block diagram of a terminal including a round type buffer, 

[21 ] FIGS. 8A and S3 are detailed diagrams of chunk headers according to em- 

bodiments of the present invention; 

[22] FIG. 9 illustrates a process of reading chunk audio data stored in a buffer, decoding 

the chunk aidio data, synchronizing the decoded chunk audio data with video data, 
and outputting the synchronized audio and video data; and 

[23] FIG. 10 is a flowchart illustrating a method of calculating an initial position of 

audio data according to an embodiment of the present invention. 

Best Mode 

[24] According to an aspect of the present invention, there is provided a nultimedia 

data reproducing apparatus comprising: a decoder receiving AV data, decoding the AV 
data, and reproducing the AV data in synchronization with predetermined markup data 
related to the AV data; and a markup resource decoder receiving location information 
of video data being reproduced by the decoder, calculating a reprodring location of 
the markup data related to the video, and transmitting the reproducing location of the 
markup data to the decoder. 

[25] According to another aspect of the present invention, there is provided a method of 

receiving audio data, the method comprising: receiving meta data including attribute 
information of audio data from a server, calculating initial position information of the 
aidio data, transmission of which is requested, according to the attribute information 
included in the meta data; and transmitting the calculated initial position information to 
the server and receiving the aidio data corresponding to the initial position. 

[26] According to another aspect of the present invention* there is provided a method of 

calculating a location of aidio data, the method comprising: converting initial time in- 
formation of data, transmission of which is requested, into the number of frames 
included in the audio data; converting the number of frames into initial position in- 
formation of a chunk, which is a transmission unit of the aidio data; and calculating 
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byte position information corresponding to the initial chunk information. 

[27] According to another aspect of the present invention, there is provided a recording 

medium having recorded thereon audio raeta data comprising: information regarding a 
compression format of axho data; information regarding the number of bytes allocated 
to a single frame included in the audio data; time information allocated to the single 
frame; information regarding the size of chunk data, which is a transmission unit of the 
audio data, and information regarding the size of chunk head; and location information 
regarding a server in which the audio data is stored. 

[28] According to another aspect of the present invention, there is provided a recording 

medium having recorded thereon an audio data structure of comprising: a chunk head 
field including synchronization information determining a reference point in time for 
reproducing the audio data; and an aidio data field in which frames forming the audio 
data are stored. 

[29] According to another aspect of the present invention, there is provided a computer 

readable medium having recorded thereon a computer readable program for 
performing a method of receiving audio data and a method of calculating a location of 
audio data. 

Mode for Invention 
[30] Hereinafter, the present invention will now be described more folly with reference 

to the accompanying drawings, in which exemplary embodiments of the invention are 
shown. 

[31] A file request message used when a terminal requests a complete audio.ac3 file 

from a server is: 
[32] GET /audio.ac3 HTTP/1.0 

[33] Date: Fri, 20 Sep 1996 08:20:58 GMT 

[34] Connection: KeepAHve 

[35] User-Agent: ENAV 1 .0(Manufacturer). 

[36] A response message that the server transmits to the terminal in response to the file 

request message is: 
[37] HTTP/1.0 200 

[38] Date: Fri, 20 Sep 1996 08:20:58 GMT 

[39] Server: ENAV 1 .0<NCS A/1 .5.2) 

[40] Last-modified: Fri, 20 Sep 1996 08:17:58 GMT 

[41] Content-type: text/xml 

[42] Content-length: 655360. 
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[43] A file request message used when the terminal requests a certain range of the 

audio.ac3 file from the server is: 
[44] GET /audio.ac3HTTP/1.0 

[45] Date: Fri, 20 Sep 1996 08:20:58 GMT 

[46] Connection: KeepAlive 

[47] User^gent ENAV L0(Manifacturer) 

[48] Range: 65536-131072. 

[49] If the terminal requests data from a 65536 byte position to a 131072 byte position 

of the ajdio.ac3 file as shown above, a response message from the server is: 
[50] HTTP/1.0 200 

[51] Date: Fri, 20 Sep 1996 08:20:58 GMT 

[52] Server: ENAV 1.0(NCSA/L5 .2) 

[53] Last-modified: Fri, 20 Sep 1996 08: 17:58 GMT 

[54] Content-type: text/xml 

[55] Content-length: 65536. 

[56] FIG. 2 is a block diagram of a terminal. Referring to FIG. 2, a terminal 200 

includes an MPEG data buffer 201, a markup resource buffer 202, an MPEG decoder 
203, and a markup resource decoder 204. The terminal 200 can receive data from a 
sewer 210 via a network or from a recording medium 205 such as a disc. 

[57] A markup resource stored in the server 210 is transmitted to the markup resource 

buffer 202, and decoded by the markup resource decoder 204. Video data stored in the 
recording medium 205 is transmitted to the MPEG data buffer 201 and decoded by the 
MPEG decoder 203. The decoded video and markup resource are displayed together. 

[58] FIG. 3 is a block diagram of a server. 

[59] A server 300 includes a data transmitter 301, an audio sync signal insertion unit 

302, and a markup resource storage unit 303. The data transmitter 301 transmits data to 
and receives data from a plurality of terminals 310, 320, and 330. The audio sync 
signal insertion unit 302 inserts a sync signal for siimltaneaisly reprodjeing audio and 
video by synchronizing the audio and video when the video is reprodbced. The markup 
resource storage unit 303 stores markup resource data such as an axiio.ac3 file. 

[60] FIG. 4 illustrates a process by which a terminal receives audio data from a server 

using meta data. 

[61] A terminal 410 transmits a request message requesting meta data (audio.acp) to a 

server 420 in step 40 1 . The server 420 transmits a response message to the terminal 
410 in response to the request message in step 402. Then, the server 420 transmits the 
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meta data to the terminal 410 in step 403. 



[62] The aidio meta data aidio.acp file is: 

[63] <media versions 1 .0 f > 

[64] <data name= , format' value='audio/ac3' /> 

[65] <data name= r byteperfrarae' value=*l 20' /> 

[66] <data name='mspe^f^arne , value=32 1 /> 

[67] <data name^chunktype* value= 1 1 /> 

[68] <data name=chunksize' value=8 1 92' /> 

[69] <data name^chunkheader' value=2 1 ' /> 

[70] <data najne^Iocation' va]ue^^^ttpy/wwwxompany.co^n/ac3/aKiio.ac3 , /> 

[7i] </media>. 

[72] As indicated above, the audio meta data includes an audio file format, the number 



of bytes per frame, time for reproducing a single frame, a chunk type, the size of 
chunk, the size of a chunk header, and a location of stored audio data. The terminal 
410 stores the received audio meta data aidio.acp file in a buffer memory included in 
the terminal 410. Here, the audio.acp meta data can be read from a disc or received 
from a server via a network. The aidio.acp meta data can also be transmitted as any 
type including a file type. 
[73] The terminal 410 receives the audio.acp meta data and calculates a location of 

aidio data to be read in step 404. A method of calculating the location of the aidio 
data will be described later. When the location is calculated, the terminal 410 transmits 
a message requesting the actual audio file aidio.ac3 to the server 420 in step 405. The 
server transmits a response message to the terminal 410 in response to the audio file 
request message in step 406 and then transmits audio.ac3 audio data to the terminal in 
step 407. 

[74] FIG. 5 is a table showing request messages and response messages used to 

communicate between a terminal and a server. 
[75] Referring to FIG. 5, messages transmitted from a tenninal to a server include a 

meta data request message and an ac3 file request message, and messages transmitted 

from the server to the tenninal include response messages in response to the request 

messages. 

[76] FIG. 6 illustrates the configiration of an aidio.ac3 file. 

[77] An audio.ac3 file includes chunk header fields 610 and 630 and ac3 aidio data 

fields 620 and 640. The chunk header fields 610 and 630 include synchronization in- 
formation determining a temporal reference point for reproducing audio. The ac3 aidio 
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data fields 620 and 640 include aidio data including a plurality of frames. A single 
aidio frame can be included in a single ac3 aidio data field, and the single aidio 
frame, such as a fourth frame 624, can be divided into two. 
[78] A process of calculating a location of aidio data that a terminal requests from a 

server is as follows. 

[79] The terminal calculates the number of bytes corresponding to an initial position 

requested by the terminal by analyzing aidio meta data aidio.acp stored in a buffer 
memory included in the terminal. For example, if the initial position of a file requested 
by the terminal is 10 minutes 25 seconds 30 milliseconds, the terminal converts the 
initial position into a unit of milliseconds in advance. In this case, 10:25:30 = 625,030 
milliseconds. The calculated value is converted into the number of frames using the re- 
producing time per frame (ms/frame) used in the audio meta data. 

[80] The number of frames is calculated as 625,030/32 = 19,532, and accordingly, an 

audio data frame following the 19,532th frame is the initial position. Also, a chunk to 
which the 19,533* frame belongs is calculated. That is, the size of 19,532 frames is 
calculated as 19,532*(the number of bytes allocated to a frame) = 19,532* 120 = 
2,343,840 bytes. 

[81] The size of data included in the ac3 aidio data field 620, not including the chunk 

header field 610, is (the size of chunk - the size of chunk header) = 8,192 - 21 = 8,171. 
When the size of total frames is divided by the size of data, 2,343,840/8,171 = 286 
chunks. Therefore, aidio data starting from a 287 * chunk is received. Here, a location 
of the 287* chunk converted into a unit of bytes is 285*(the size of chunk), a 
2,342,912* byte position. 



[82] The terminal transmits the following message including byte position information 

calculated as described above to the server to receive audio data: 
[83] GET /aidio.ac3 HTTP/1.0 

[84] Date: Fri, 20 Sep 1996 08:20:58 GMT 

[85] Connection: KeepAlive 

[86] User Agent: ENAV 1 .0(Manufacturer) 
[87] Range: 2342912-2351 103. 

[88] The server transmits an audio data file audio.ac3 to the terminal. Here, the ac3 file 

can be read from a disc or received from the server via a network. 
[89] FIG. 7 is a block diagram of a terminal including a round type btffer. 

[90] Referring to FIG. 7, a terminal 700 stores a received markup resource data 



audio.ac3 file in a markup resource buffer 702 included in the terminal 700. The 
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markup resoorce buffer 702 is a round type buffer and consecutively receives and 
stores data in nultiple chunk units. A markup resource decoder 704 decodes the 
aidio.ac3 file stored in the round type markup resource biffer 702 and outputs the 
decoded aidio.ac3 file. 

[91] DVD AV data stored in a recording medium 705, such as a disc, is transmitted to a 

DVD AV data buffer 701, and a DVD AV decoder 703 decodes the DVD AV data. 
Finally, the DVD AV data decoded by the DVD AV decoder 703 and the aadio.ac3 
file decoded by the markup resource decoder 704 are reproduced sinultaneously. 

[92] FIGS. 8A and ffl are detailed diagrams of chunk headers according to em- 

bodiments of the present invention. 

[93] A chunk header according to an embodiment of the present invention can be 

defined to follow the ISCMEC-13818 Part 1 and a DVD standard such that a DVD file 
can be easily decoded. As shown in FIG. 8A, in a program stream (PS), the chunk 
header includes a pack header 810, a system header 820, and a PES header 830, which 
are written in ISO/IEC-1381 8. Also, only one of the pack header 810 and the system 
header 820 can be included in the chunk header. As shown in FIG. fB, in a transport 
stream (TS), the chunk header includes a TS packet header 840 and a PES header 850. 

[94] A presentation time stamp (PTS) of chunk data is included in the PES headers S30 

and 850. If a fragmented frame exists at an initial position of an audio data field, the 
PTS indicates an initial position of a full frame. 

[95] FIG. 9 illustrates a process of reading chunk audio data stored in a buffer, decoding 

the chunk aidio data, synchronizing the decoded chunk audio data with video data, 
and cutputting the synchronized aidio and video data. 

[96] Synchronization between chunk audio and DVD video is performed as follows. 

[97] A markup resource decoder 704 confirms a reproducing time position of current 

DVD video. If it is assumed that the reproducing time position is 10 minutes 25 
seconds 30 milliseconds as above, a location of relevant chunk audio can be easily 
determined. A method of reproducing audio using an ECMAScript will now be 
described using APIs. 

[98] [obj]. elapsed JTime is API transporting reproducing time position information of 

the DVD video. 

[99] Also, regardless of whether synchronization with the DVD video is required and 

whether synchronization with the reproducing time position information of the DVD 
video is required when the chunk audio is synchronized and reproduced, the API: [obj] 
.playAudioStream(Tittp-y/wwwxompany.corn/aKlio.acp\ , 10:25:30^true), designating 




where the chunk aidio is located is required. 
[100] Hie above API indicates that a designated aidio meta file, such as 

'http-y/www xompany.com/audio.asp', has been downloaded and decoded, and when 
the DVD video is being reproduced for 10 minutes 25 seconds 30 milliseconds until a 
relevant point in time, reprodction of the chunk aidio starts by synchronizing an 
audio frame obtained by a PTS calculation of a chunk ajdio stream corresponding to 
the time. 

[101] However, the API below is used when an audio clip is reprodiced when the ajdio 

clip is reprodiced as an infinite loop without synchronization or when the aidio clip is 
reproduced only once: 

[102] [obj].playAudioC!ipChttpy/ww\v.company.com/aidio.acp', -1). 

[103] The API is used for downloading and decoding a designated audio meta file from 
Tutpi//www.company.com/aidio.acp', downloading a relevant audio clip to a markup 
resource biffer 702, and reprodicing the audio clip using the infinite loop. 

[ 104] Here, instead of forming a file including the audio meta data, it is also possible to 

calculate the audio meta data using a program language (for example, Javascript, Java 
language) or a tag language (for example, SMIL, XML), directly extract information 
related to frames, and reproduce the audio clip. 

[105] Also, embodiments of the present invention can be applied to not only audio data 
but also multimedia data configured with a fixed bitrate, for example, media data such 
as video, text and animation graphic data. That is, if the video, text and animation 
graphic data have a chunk data configuration, it is possible to reprodice the video, text 
and animation graphic data in synchronization with the DVD video. 

[106] FIG. 10 is a flowchart illustrating a method of calculating an initial position of 
aidio data according to an embodiment of the present invention. 

[107] Reprodiction initial time information of an aidio file is converted into the number 
of frames forming aidio data in step S1010. The number of frames is converted into an 
initial position of a chunk in step SI 020. Byte position information corresponding to 
the initial position of the chunk is calculated in step S1030. The byte position in- 
formation is transmitted to a server in step SI 040, and the aidio data, starting from the 
desired position, is received from the server. 

[ 108] The invention can also be embodied as computer readable codes on a computer 
readable recording medium. The computer readable recording medium is any data 
storage device that can store data which can be thereafter read by a computer system. 
Examples of the computer readable recording medium include read-only memory 
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(ROM), random-access memory (RAM), CD-ROMs, magnetic tapes, floppy disks, 
optical data storage devices, and carrier waves (such as data transmission through the 
The Internet). The computer readable recording medium can also be distributed over 
network coupled computer systems so that the computer readable code is stored and 
executed in a distributed fashion. 
[109] While this invention has been particularly shown and described with reference to 
preferred embodiments thereof, it will be understood by those skilled in the art that 
various changes in form and details may be made therein without departing from the 
spirit and scope of the invention as defined by the appended claims. The exemplary 
embodiments should be considered in descriptive sense only and not for purposes of 
limitation. Therefore, the scope of the invention is defined not by the detailed de- 
scription of the invention but by the appended claims, and all differences within the 
scope will be construed as being included in the present invention. 
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Claims 

1. A rrultiraedia data reproducing apparatus comprising: 

a decoder receiving AV data, decoding the AV data, and reproducing the AV 
data in synchronization with predetermined markup data related to the AV data; 
and 

a markup resource decoder receiving location information of video data being 
reproduced by the decoder, calculating a reproducing location of the markup data 
related to the video, and transmitting the reproducing location of the markup data 
to the decoder. 

2. The apparatus of claim 1, further comprising a markup resource buffer 
receiving and storing the markup data. 

3. The apparatus of claim 2, wherein the markup resource buffer is a round type 
buffer and stores markup resource data related to the AV data in predetermined 
chunks units. 

4. The apparatus of claim 3, wherein the chunk comprises: 

a chunk header field including synchronization information determining a 
reference point in time for reproducing audio; and 
an audio data field in which audio frames are stored. 

5. The apparatus of claim 1, wherein the markup data is audio data. 

6. A method of receiving audio data, the method comprising: 

receiving meta data including attribute information of audio data from a server; 
calculating an initial position information of the audio data, transmission of 
which is requested, according to the attribute information included in the meta 
data; and 

transmitting the calculated initial position information to the server and receiving 
the audio data corresponding to the initial position. 

7. The method of claim 6, wherein the meta data comprises: 
information regarding a compression format of audio data; 

information regarding the number of bytes allocated to a single frame included in 
the audio data; 

time information allocated to the single frame; 

information regarding the size of chunk data, which is a transmission unit of the 

aidio data, and information of the size of chunk head; and 

location information regarding a server in which the audio data is stored. 
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[8] 8. The method of claim 6, wherein the calculating the initial position information 

comprises: 

receiving time information indicating an initial position of the aidio data, 
transmission of which is requested; 

converting the time information into information indicating the number of 
frames forming the aidio data; 

converting the information indicating the number of frames into initial position 
information of a chunk forming the audio data; and 

calculating byte information corresponding to the initial position information of 
the chunk. 

[9] 9. A method of calculating a location of aidio data, the method comprising: 

converting initial time information of data, transmission of which is requested, 
into the number of frames included in the aidio data; 

converting the number of frames into initial position information of a chunk 
which is a transmission unit of the aidio data; and 

calculating byte position information corresponding to the initial chunk in- 
formation. 

{ 10] 10. Tne method of claim 9, wherein the chunk comprises: 

a chunk header field including synchronization information determining a 

reference point in time for reproducing audio; and 

an audio data field in which frames forming the audio data are stored. 

[11] 1 1 . A recording medium having recorded thereon aidio meta data comprising: 

information regarding a compression format of audio data; 
information regarding the number of bytes allocated to a single frame included in 
the aidio data; 

time information allocated to the single frame; 

information regarding the size of chunk data, which is a transmission unit of the 
aidio data, and information of the size of chunk head; and 
location information regarding a server in which the aidio data is stored. 
[12] 12. A recording medium having recorded thereon an aidio data structure of 

comprising: 

a chunk head field including synchronization information determining a 
reference point in time for reproducing the aidio data; and 
an audio data field in which frames forming the audio data are stored. 
[13] 13. The method of claim 12, wherein the chunk header field includes at least one 
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of a pack header field and a system header field, which are defined in an MPEG- 
2 standard. 

14. The method of claim 12, wherein the chunk header field includes a TS packet 
header field, which is defined in an MPEG-2 standard. 

15. The method of claim 12, wherein the chunk header field includes a PES 
header field, which is defined in an MPEG-2 standard. 

16. A computer readable medium having recorded thereon a computer readable 
program for performing a method of receiving audio data comprising: 
receiving meta data including attribute information of audio data from a server, 
calculating an initial position information of the aidio data, transmission of 
which is requested, according to the attribute information included in the meta 
data; and 

transmitting the calculated initial position information to the server and receiving 
the axlio data corresponding to the initial position. 

17. A computer readable medkim having recorded thereon a computer readable 
program for performing a method of calculating a location of audio data 
comprising: 

converting initial tune information of data, transniLSSion of which is requested, 
into the number of frames included in the audio data; 
converting the number of frames into initial position information of a chunk 
which is a transmission unit of the audio data; and 

calculating byte position information corresponding to the initial chunk in- 
formation. 
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Abstract 

Provided are a nnltimedia data decoding apparatus, a method of receiving audio data using 
an HTTP protocol and an aidio data structure used for the apparatus and method. The 
multimedia data reprodring apparatus comprising: a decoder receiving AV data, decoding the 
AV data, and reprodicing the AV data in synchronization with predetermined markup data 
related to the AV data; and a markup resource decoder receiving location information of video 
data being reproduced by the decoder, calculating a reprodbcing location of the markup data 
related to the video, and transmitting the reprodbcing location of the markup data to the decoder. 
Audio data is received using the HTTP protocol, not a complex audioivideo streaming protocol, 
and is output in synchronization with video data. 
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HTTP/ 1.0 200 

Date: Fri, 20 Sep 1996 08:20:58 GMT 
Server: ENAV 1 .0(NCSA/1 .5.2) 
Last-modified: Fri, 20 Sep 1996 08:17:58 GMT 
Content— type: text/xml 
Content-length: 655360 
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( START ) 



CONVERT REPRODUCTION INDICATING 
TIME INFORMATION INDICATING AUDIO 
FILE INTO INFORMATION OF NUMBER 
OF FRAMES 



CONVERT INFORMATION INDICATING 
NUMBER OF FRAMES INTO INITIAL 
POSITION INFORMATION OF CHUNK 



— S1010 



— S1 020 



CALCULATE BYTE POSITION INFORMATION 
CORRESPONDING TO INITIAL POSITION 
INFORMATION OF CHUNK 



TRANSMIT CALCULATED BYTE POSITION 
CORRESPONDING TO BIGINNING POSITION 
INFORMATION TO SERVER 
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— S1040 
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